home *** CD-ROM | disk | FTP | other *** search
- On 25-May-97, --==MURRAY==-- wrote:
-
- >Say for a horizontal scrolling system. Using offset to move along
- >and then every 16 or 32 pixels, it copys the screen across to the
- >left, draws the side, resets the screen offset and continues.
-
- Okay, you realize this is never going to be very fast. Transfering
- such a huge block of ChipRAM via the blitter is a BIG bottleneck...
-
-
- >My problem is that I need the screen swap and screen offset to
- >happen at the same time, because otherwise there is a flicker as
- >either the screen offset moves across before the screen has been
- >swapped OR the screen is swapped before the screen offset is
- >reset.
-
- I assume you have the auto Bob Updates & Screen Swapping
- deactivated (Bob Update Off), right?
-
-
- >I've tried Wait Vbl and Vbl Wait X and Wait Raster in all possible
- >positions to try and get the commands to have been executed
- >before the next cycle is drawn.
-
- >I can only think that as soon as either of these commands are
- >called, it must immediately draw the screen.
-
- Right!! You are having a bit of trouble which is really more AMOS's
- fault (sometimes it tries too hard to be "friendly")...
-
- To avoid these problems you need to go "low level" in your AMOS
- programming:
-
- Deactivate the automatic Bob Updates, Screen Swapping, etc.
-
- Bob Update Off : Autoback 0
-
- and the MAIN culprit which most people overlook...
-
- Auto View Off
-
-
- Now, using a structure such as:
-
- Repeat
- Bob Clear
- Some_Code_Doing_Many_Complex_Things
- Some_More_Code_Handling_The_Scrolling
- Bob Draw
-
- Screen Swap : View : Wait Vbl
- Until STAGECOMPLETE
-
-
- The View will cause EVERYTHING to be updated "at once" which
- will allow you to gain control similiar to that found in BLITZ or
- Assembler.
-
- It will certainly be almost impossible to have this updated in 1 Vbl,
- but this structure should prevent the "glitches".
-
-
-
- Hope that helps...
-
- Garfield
-
-
-
-
-
-